Internet Protocol Security (IPSec) Protocol provides for secure communications over inherently insecure networks, for secure Virtual Private Network (VPN) services, for example. Secure communication using IPSec involves negotiating security parameters using IPSec messages and then establishing IPSec Security Associations (SAs) between IPSec clients at an access system and a host system or a security gateway. The process is normally initiated by the access system and requires prior knowledge of an address of the host system or security gateway and either a pre-shared key or mutual public key certificates between the client and the host or gateway.
Security parameter negotiation is typically performed using the Internet Key Exchange (IKE) protocol and consists of two phases. Phase one is the process of creating a secure tunnel for IPSec SA negotiation and is identified by the Internet Security Association and Key Management Protocol (ISAKMP) SA. The second phase is the Authentication Header (AH) or Encapsulating Security Protocol (ESP) SA negotiation process, depending upon the data security services to be supported. IPSec AH provides for data authentication but not protection. ESP, on the other hand, protects data.
The ISAKMP SA negotiation is used to agree upon security attributes such as an encryption algorithm, a hash algorithm for signing, and an authentication method, and for Diffie-Hellman (DH) key exchange. The access system initiates negotiations, which are completed once mutual keys have been derived at both the access system and the host or gateway and upon the verification of the identity of the two parties.
IKE phase two is performed by using the ISAKMP SA to negotiate ESP SAs which will protect actual data traffic, for example. Again, the IPSec client at the access system initiates, keys are agreed upon, and the SAs are created, one for each direction. Each SA is uniquely identified by a Security Parameter Index (SPI).
User traffic originating at the access system or at the host system or a system associated with the security gateway is protected by an SA that is identified by the specific SPI. As described above, two SAs are created for 2-way communication. Any time a network address of an access system changes, where the access system is a mobile communication device and a handoff is made to a new location which assigns the access system a different network address, the IPSec SAs must be re-negotiated.
IPSec was designed primarily for fixed networks and therefore is not very “mobile friendly”. Some of the primary drawbacks of IPSec for application to clients on mobile communication devices include latency and resource burden. Latency involved in re-negotiation of IPSec SAs every time a network layer handoff is performed can lead to substantial loss of data, and potentially greater impact in the case of real-time services. In addition, depending upon the frequency of handoffs, the amount of overhead and processing required for creating and re-negotiating SAs by a host system or security gateway could potentially be very large, which may occupy or overload available resources.
One mechanism which avoids having to re-negotiate SAs every time a handoff occurs is to have an IPsec client, operating on a mobile communication device, for example, create SAs using a permanent home address as one of the endpoints of the SAs instead of an obtained IP address. This ensures that SAs do not have to be re-negotiated, since the client used its permanent identity to create the SAs even though a new address is obtained every time a handoff is performed. The main drawback of this approach is that traffic now would be routed via the mobile device's home network and then re-routed to the access network where the device is located. This causes not only increased traffic to the home network but also inefficient routing (not shortest path) in both the directions. Depending upon the IPSec mode used, this technique can cause lot of wireless resource consumption because of multiple-tunnelling.